Companies today are tasked with implementing solutions for many types of integration challenges within their respective enterprises. Many of these challenges involve issues of application integration (e.g., integration among and/or between software applications and/or other systems) and fall into common patterns.
For example, a first area relates to propagation of similar business objects from one system to multiple other systems, such as, for example, in an order status change or a product price change. A second area relates to synchronization of similar business objects between two or more systems to obtain a single view, such as, for example, a real-time synchronization of customer, product registration, product order, and product SKU information among several applications. This is one of the most common issues requiring an integration solution. In a one-way synchronization, there generally is one system (e.g., resource) that acts as a data source and one or more resources that are targets of the synchronization. In a two-way synchronization, every resource often is both a potential source and target of a synchronization. There generally is not a single resource that acts as the primary data resource. Thus, a change to any resource should be reflected in all other resources. A third area involves information joined from multiple sources into a common destination system, such as, for example, communicating pharmacy customer records and prescription transactions and website data into a central application and database.
Various tools have been provided that enable a user to design and deploy solutions that address these challenges using, for example, the publish-and-subscribe model or one of its variants. The publish-and-subscribe model is a specific type of message-based solution in which messages are exchanged anonymously through a message broker. Applications that produce information that needs to be shared make this information available in specific types of recognizable documents that they publish to the message broker. Applications that require information subscribe to the document types they need.
At run time, the message broker receives documents from publishers and then distributes the documents to subscribers. The subscribing application processes or performs work using the document and may or may not send a response to the publishing application.
In a typical system, an integration server or applications running on an integration server publish documents to a broker. The broker then routes the documents to subscribers located on other integration servers. The integration server and the broker share a fast, efficient process for exchanging documents across the entire system.
Brokers can be linked to form units known as territories, and brokers that form a territory may sometimes function as a single logical broker. Clients that connect to one broker in a territory can automatically exchange documents with clients connected to any of the brokers in the territory. Territories can be organized in any desired way, e.g., to take into account factors such as, for example, geographical distribution of clients and/or back-end services, the types of services offered, actual and/or expected traffic, actual and/or expected processing loads, etc. Territories thus may help support scalability by allowing one to segment traffic among multiple brokers, while still treating the brokers as a single operational unit.
When brokers operate in a territory, they maintain the same set of document types and client group definitions. Typically, these objects are initially synchronized when a broker joins a territory. Any changes that occur to these objects on one broker should be automatically propagated to the other brokers in the territory. In other words, after a broker becomes a member of a territory, it then is responsible for notifying its peers of any changes that occur to its own document types or client groups.
When a given broker in a territory receives such a notification, it immediately applies the change to its own metadata. Because these metadata changes are self-propagating, one can make a change to a document type or client group on any broker and expect that change to automatically be applied to all brokers in the territory. Every broker in a territory therefore should have knowledge about the other brokers, at least in that specific territory. For example, as indicated above, when a change occurs to client groups or document types in a broker, that broker initiates a connection with all other brokers and propagates the changes.
Unfortunately, however, the entire responsibility for propagating the change lies with the single broker. It thus follows that propagation delays, failures, and other problems with the network and/or that individual broker may cause the synchronization between brokers to be lost.
Thus, it will be appreciated that there is a need in the art for improving synchronization among brokers in and across territories.
Certain example embodiments address this problem by calculating and/or making use of an optimized (e.g., shortest) route for propagation. Using the shortest route, for example, should at least in theory help ensure that the number of propagation operations is at a minimum. A single broker may propagate the same update to several other brokers, thereby reducing the overall bandwidth required.
In certain example embodiments, broker territories are formed from broker servers that are placed in different geographical locations. When a territory is formed, a least cost tree (also sometimes referred to as a minimum spanning tree or MST) is formed between the brokers in the territory and, as a result, every broker in the territory will know its nearest neighbors and will be able to propagate the changes to these brokers.
It thus will be appreciated that certain example embodiments lack a master-slave relationship as between the brokers in a territory. In this way, the brokers are all in a sense “equal” in that, for example, they all have the same responsibilities when it comes to propagating updates.
One aspect of certain example embodiments relates to having each broker calculate and updates its own minimum spanning tree, purely to determine its nearest neighbor based on the configurable criteria. The actual minimum spanning tree calculation may be performed using any suitable algorithm. The metadata flow associated with the calculations may be dynamic and work automatically between equal brokers, contrary to typical master-slave approaches.
Example advantages include reliability of propagation and bandwidth optimization.
In certain example embodiments, the least cost tree may be dynamic, and/or each broker may be configured to calculate the cost of the edges based on certain predefined parameters.
In certain example embodiments, there is provided a method of managing operations of a computer network in which a plurality of broker servers located at different respective geographical locations are divided into one or more distinct broker server territories. At each broker server in each said territory, a nearest neighbor is calculated as if the respective broker server were a node in a minimum spanning tree for its territory. Brokered messaging and/or service provision is enabled using the broker servers in the computer network. In response to a change being made to one of said broker servers, a message indicative of the change to each of the broker servers is propagated by causing each said broker server, starting with the changed broker server, to distribute the message indicative of the change to its respective nearest neighbor broker server, in managing the computer network.
In certain example embodiments, a computer-mediated network system is provided. Brokers are located at different respective geographical locations, with the brokers being divided into one or more distinct broker territories. Each said broker comprises processing resources including at least one processor and a memory. The processing resources for each said broker being configured to: calculate a nearest neighbor as if the respective broker were a node in a minimum spanning tree for its territory; cause the respective broker to cooperate with other brokers in its territory in order to provide brokered messaging and/or services to requesting client computer systems; and distribute a message indicative of a change to one of said brokers in its territory to the broker that is considered its respective nearest neighbor.
In certain example embodiments, there is provided a first broker server for use in a computer-mediated network system comprising a plurality of broker servers located at different respective geographical locations and being divided into one or more distinct broker server territories. The first broker server comprises at least one computer processor; a memory; and instructions stored on a non-transitory computer readable storage medium, performable in connection with the at least one computer processor and the memory. The instructions are performable to at least: calculate a nearest neighbor as if the first broker server were a node in a minimum spanning tree for its territory; cause the first broker server to cooperate with other broker servers in its territory to provide brokered messaging and/or services to requesting client computers; receive a direct change command from an authorized user; in response to a received direct change command, distribute a message indicative of the received direct change command to a second broker server that is considered the first broker server's nearest neighbor, so that the second broker server is updated and caused to distribute the message indicative of the received direct change command to a third broker server in its territory that is considered the second broker server's respective nearest neighbor, in propagating the direct change command through the territory; receive a indirect change command from an authorized user via an intermediary broker server; and in response to a received indirect change command, distribute a message indicative of the received indirect change command to a second broker server that is considered the first broker server's nearest neighbor, so that the second broker server is updated and caused to distribute the message indicative of the received indirect change command to a third broker server in its territory that is considered the second broker server's respective nearest neighbor, in propagating the indirect change command through the territory. No master-slave relationships exist as between broker servers in the territory for purposes of propagating changes made to the broker servers.
In certain example embodiments, there is provided there is provided a method of operating a computer network in which a plurality of broker servers located at different respective geographical locations are divided into one or more distinct broker server territories. In response to a change being made to one of said broker servers, a message indicative of the change is propagated to each of the broker servers by causing each said broker server, starting with the changed broker server, to distribute the message indicative of the change to a broker server that would be considered its nearest neighbor if a minimum spanning tree algorithm were computed considering each broker server to be a node in the minimum spanning tree. No master-slave relationships exist as between broker servers in the territory for purposes of propagating changes made to the broker servers. Edge weights for the minimum spanning tree are based on one, two, or more of the following and/or other factors: ping time responses between connected broker servers pairs; geographical distances between connected broker servers pairs; whether connected broker server pairs are either in a common LAN or separated by a WAN; whether connected broker server pairs are either mobile or stationary; and whether connected broker server pairs belong to a common one of a plurality of predefined categories.
In certain example embodiments, there are provided non-transitory computer readable storage mediums tangibly storing instructions that, when executed by at least one processor of a system, perform the above-described and/or other methods.
These aspects and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.